1). Field of the Invention
This invention relates to a computing system, in particular a computing system for accessing various resources.
2). Discussion of Related Art
The task of protecting information stored on computers is becoming increasingly difficult and complex as more and more companies are storing an ever increasing amount of data electronically. The job of keeping such information secure is even further hampered by the fact that many of the computers and databases on which this information is stored are remotely accessible through various public networks, such as the internet.
FIG. 1 illustrates an example of a typical computer network system 10, including a client 12 (e.g., a user), a network 14, a container 16, user managers 181-18N, and resources 201-20N. The client 12 is, for example, a computer, or an individual using a computer. The network 14 includes a series of points or nodes (e.g., switches, routers, etc.) interconnected by communication paths. The network may include one or more of the following: the internet, a public network, or a local area network (LAN), and a private network.
The container 16, which may be implemented on a server, includes an application 22 stored thereon. As illustrated, there is one user manager 18 for each of the resources 201-20N. Each of the resources 201-20N, which may be, for example, databases, has a plurality of various files 24 stored thereon.
The client 12 accesses the application 22 within the container 16 through the network 14. Once the client 12 has successfully gained access to the application 22, the application 22 may need to access one or more of the resources 201-20N on behalf of the client 12. Before the application 22, or the client 12, is granted access to any of the resources, the client 12 must be authenticated and authorized for access.
Authentication is the process of determining whether someone or something is actually who or what it is claiming to be. One common authentication tool uses a user identification and a password, other such tools may use digital certificates. Authorization is the process of giving someone or something permission to do or have something. Thus authentication determines who the client 12 is, and authorization determines what information the client 12 will be able to access.
Each of the user managers 181-18N authenticate and authorize the application 22, or client 12, to access the particular resource with which it is associated. The resources 201-20N may be stored on various types of servers or database services such as a Lightweight Directory Access Protocol (LDAP) server, a Database Management Software (DBMS) based server, and a file system (FS) server.
Each of the different user managers 181-18N may be unique or different amongst each other (e.g., a first user manager may be associated with an LDAP service, a second user manager may be associated with a Kerberos service, etc.) and may utilize a unique “language,” or protocol, for communicating with the application 22. Therefore, in order for the application 22 to successfully request authentication and authorization from any particular one of the user managers 181-18N, the application 22 must know which particular protocol that particular user manager utilizes and send requests and/or commands to the particular user manager in the particular language that it uses. For example, if the client 12, or the application 22 on behalf of the client, wishes to perform a high level function, such as “modify group,” on two different user managers 181 and 182, two different syntaxes are required. One of the user managers 181 may require the command in the syntax “modify_group” while another user manager 182 requires that the command be in the syntax “mg.”
Thus, the application 22 must be designed to comprehend multiple communication protocols in order to communicate with the different user managers 181-18N in the particular syntaxes that they require. As the number of communication protocols programmed within an application 22 increases, the application 22 becomes more complicated and difficult to program and manage.
Additionally, various types of authentication services may be used by the different user managers 181-18N or resources 201-20N, each of which may utilize a different login protocol module.
The application 64 can invoke multiple high level commands/requests from the various user managers 581-58N with only a single communication protocol PAPI through the common API 66. Examples of the high level commands include commands for managing users and groups of users (e.g., obtain information from a user account, create a user account, delete a user account, modify a user account, define a group, modify a group, delete a group, add a user to a group, remove a user from a group, and add a group to a group.) The application may also invoke authentication commands through the API 66 such as “login” and “logout.” In an embodiment, authentication commands that flow through the common API 66 are the same as those used in Java Authentication and Authorization Service (JAAS). These commands include login, logout, abort, and commit).
Each of the user managers 581-58N is responsible for implementing authentication and authorization services for a corresponding one of the resources 621-62N, and each of the user stores 681-68N within the container 56 is responsible for communicating with a corresponding one of the user managers 581-58N in the language/syntax/format P1, P2 . . . PN that the user manager comprehends. That is, each of the user stores 681-68N is able to communicate with the particular user manager 581-58N with the communication protocol that it understands.
That is, referring again to FIG. 1, when the client 12 is authenticated through a particular user manager 181, the appropriate principle for the client 12 is sent to the application 22. Then, when the client 12 again attempts to use one of the resources 201, the application 22 sends the principle back to the user manager 181. The user manager 181 then allows the application 22 to access the appropriate files based on the roles associated with the principle.
Each time the client 12 is authenticated by a new user manager, another principle needs to be tracked by the application 22 and/or the login context used by the application 22. As the application 22 has to manage more and more principles, it becomes more complicated and more difficult to manage.